One of the most basic services provided to business and individual customers by financial institutions such as banks and related entities (hereinafter referred to generically as banking entities) is the maintenance of customer accounts. Customers may establish a variety of different customer accounts with a variety of different banking entities. Such accounts may range in type from simple deposit accounts (e.g., checking and savings accounts, wherein the account represents cash assets of the customer being held by the banking entity), to credit or debt accounts, to complicated brokerage accounts (wherein the account may represent a variety of different asset or debt vehicles of varying cash value being held or managed by the banking entity for the customer). A single customer may have a variety of different accounts, of the same or different types, with the same banking entity. A simple schematic illustration of the information flow between an exemplary banking entity 20 and customers 22 with regard to accounts 24 established by customers 22 with the banking entity 20 is provided in FIG. 1.
A key feature of most customer accounts 24 with a banking entity 20 is the ability of a customer 22 to affect a variety of transactions that alter the account balance. For example, for a conventional cash deposit account, a customer may initiate daily account transactions 26 as desired. Such account transactions 26 may include, for example, conventional deposits to or withdrawals from the account assets. Such deposit and withdrawal transactions 26 may be initiated using various conventional mechanisms, such as a written paper check, automatic teller machine (ATM) transaction, electronic funds transfer (EFT), etc.
More sophisticated individual and commercial customers 22 also may transfer money between various accounts 24 owned by the customer 22 and held by the same banking entity 20 by the use of a type of transaction hereinafter referred to as a sweep 28. Sweeps 28 may be executed automatically by the banking entity 20 based on sweep rules 30 that are established by the customer 22 with the banking entity 20. For example, a customer 22 may set up a sweep rule 30 whereby a set or variable amount of funds are transferred between selected accounts 24 on particular pre-selected days, at pre-selected times every day, or if certain conditions are met, such as if an account balance exceeds or falls below a pre-established threshold. The amount of funds to be swept between accounts 24 may be a fixed or variable amount defined by the sweep rules 30 that are established by the customer 22. For example, a customer 22 may set up a sweep rule 30 whereby sufficient funds are swept between accounts 24 to maintain a desired balance (e.g., a zero balance) in one of the accounts 24 after the sweep 28 is performed.
A customer also may establish sweep rules 30 with a banking entity 20 where the customer has an account whereby funds are transferred automatically or swept 29 from the customer's account at one banking entity to an account (another account of the same customer or an account belonging to a different customer) at another banking entity. Such inter-banking entity sweep rules 30 are similar to intra-banking entity sweep rules 30, in that the conditions and character of the transfer 29 may be predefined such that the sweep 29 can occur automatically without specific action by the customer at the time of the transaction. However, in this case, the sweep 29 is between accounts at different banking entities, rather than between accounts held within the same banking entity 20.
In addition to customer initiated or defined daily transactions 26 and sweeps 28, 29, the banking entity 20 itself may take actions that affect customer account balances. For example, the banking entity 20 may apply interest payments and/or service charges 32 to customer accounts 24 based on pre-defined conditions (e.g., account balance, time of the month etc.), as specified in the customer's agreement with the banking entity 20.
Daily customer transactions 26, sweeps 28, 29, interest payments and service charges 32, and the like all affect the customer's account balance. Good business practices, as well as government regulations, require that the account balance for each account 24 maintained by the banking entity 20 be updated accurately to reflect these various account activities which affect the account balance. The banking entity 20 generates account balance and transaction information reports, known as statements 34, that provide an accurate report of account balances and transactions affecting those balances to their customers 22. Such statements may be provided to customers 22 on a periodic basis (e.g., monthly for individual customers to as often as daily for certain business customers), or on-request, including in real-time. In addition, the banking entity 20 itself must maintain an accurate accounting of all of its customer accounts in aggregate. The banking entity may generate a daily report of the banking entity's position, taking into account all customer account balances.
All modern banking entities employ computer based accounting systems to maintain and update customer account balances and to generate account balance and transaction statements for customers. (A third party technology service provider often provides the account processing for the banking entity.) Such computer based accounting systems post or apply transactions which affect account balances to the customer accounts affected thereby to maintain accurate and official account balances. Transactions affecting account balances must be “final posted” or accounted for by the banking entity at least once per business day. In current computer based systems for account processing, the final posting of daily transactions (e.g., deposits and withdrawals) to accounts, the pre-established sweeping of funds between accounts within the banking entity or between banking entities, the application of interest and service charges to accounts, and the generation of account balance and transaction statements, as well as general account maintenance functions, typically occur once per day during an end of day account processing period. Typically, the final or official posting for all of the accounts maintained by a particular banking entity occurs during a single end of day account processing period. All paper-based transactions (e.g., checks) affecting account balances are accumulated for batch posting during the end of day account processing period. Daily electronic transactions (e.g., teller, ATM transactions, point of sale (POS) transactions, or Automatic Clearing House (ACH) transactions) may either be posted to the customer's account in real-time or accumulated for later batch posting with other transactions during the end of day account processing period. If the electronic transactions are accumulated for later batch posting, a secondary unofficial database of account balances may be maintained by the banking entity. Account balances in the secondary database are updated in real-time in response to electronic transactions, thereby to provide an unofficial current account balance to customers. The secondary database is updated daily with the results of the daily end of day batch processing for the account, which takes into account non-electronic and other activities affecting the account balance.
Under currently employed account processing systems and methods, end of day batch account processing occurs each day at some pre-scheduled time for groups of accounts (often all of the accounts) held by a banking entity. An exemplary general sequence of the account processing which occurs during the end of day batch account processing period is as follows:                1. Stop day/Start end of day. All accounts being processed are closed to daily transactions for Day N. Daily transactions affecting an account balance which are received after stop day will be considered next day transactions and will not be posted until the next day's processing.        2. Pull in transactions. All customer account transactions (daily transactions) for Day N are gathered for processing.        3. Process sweeps between accounts. Pre-established sweep rules are applied to the accounts being processed and funds are transferred automatically between accounts based on those rules.        4. Post transactions. Day N transactions are posted to the accounts being processed.        5. Apply interest and service charges to accounts based on account balances at this point.        6. Generate account balance and transaction statements for Day N.        7. Open accounts for Day N+1 daily transaction processing.        
It should be noted that not all of the steps listed above necessarily are applied to all accounts being processed every day. Also, many modifications and variations in the ordering of the steps listed above and in the way each step is performed have been developed to improve account processing efficiency. Such modifications may include, for example, grouping together related accounts for processing together and looking ahead in the process for certain accounts or groups of related accounts to estimate the effect of steps later in the process on the account balances established by steps earlier in the process. Furthermore, the handling of other occurrences not listed above, but that may affect account balances, also are performed during the end of day batch account processing period. Examples of such other occurrences affecting account balances include exceptions (unusual occurrences affecting account balances, such as overdrafts) and adjustments (the adjustment of account balances to correct past day's posting errors, such as when a transaction was posted in error to the wrong account on a previous processing day). The main point is that in currently employed automated account processing systems and methods all of the steps necessary to final post to account balances all of the activities that may affect the account balances typically are performed during a single daily batch account processing period.
Note that the first step to occur during the end of day batch account processing period is the effective closing, for daily transaction processing (Day N), of all of the accounts being processed (e.g., typically all of the banking entity's accounts). During the end of day batch account processing period, all of the accounts being processed are effectively closed to all daily transactions affecting the account balances. After the end of day batch account processing is complete, all of the accounts being processed are opened up to daily transactions once again, but only for next day transactions (for Day N+1). To reduce the effect on customers of their accounts being effectively closed during the end of day batch account processing period, the end of day processing of accounts typically is performed during a period of likely low customer account activity, such as in the middle of the night. However, in a global economy there is no such quiescent period.
Although less typical, there currently also exist automated account processing systems and methods which operate continuously, rather than in a batch processing mode. In such “real-time” account processing systems and methods, final posting of all transactions affecting account balances occurs as each transaction is received. Such continuous systems typically are employed by banking entities serving a limited client base and offering limited types of customer transactions affecting account balances. It should be noted that in such current continuous account processing systems and methods each account is, at any one time, open for posting of daily transactions for a single given day and closed for all other days. Thus, all transactions are posted as daily transactions on the day they are received. (In such systems and methods an end of day process is implemented wherein all of the accounts for a given banking entity are closed for daily transaction posting for one day and opened for the next day. Interest and service charge transactions and account balance and transaction statement generation also may occur during this end of day processing period.) Thus, although such real-time account processing systems and methods do not accumulate daily transactions for posting during a single end of day batch processing period, since each account is open for posting of daily transactions only for one day at any one time, it is clear that most of the limitations of current automated end of day batch account processing systems and methods, to be discussed in more detail below, apply also to such current real-time account processing systems and methods.
In the current methods of automated account processing, at any one time an account is open for processing of transactions for a given day and closed for all other days. Once an account is closed for account processing for a given day (Day N), no more transactions to or from that account (except for adjustments for past posting errors) may be made for that day. This can adversely affect a customer's ability freely to move funds between accounts such that funds are available in an account where and when the customer wants them to be.
An example of the limiting effect of current account processing systems and methods as applied to transactions between accounts in a global economy context will be described now with reference to the time line diagram presented in FIG. 2. Consider a customer with international operations who has accounts in Hong Kong 36 and Los Angeles 38 (e.g., with different national organizations of the same global banking entity). When the Hong Kong banking entity closes accounts for end of day processing on Tuesday (e.g., at midnight local time) all subsequent daily transactions involving the Hong Kong account 36 will be Wednesday transactions. However, the Los Angeles banking entity still is open for Tuesday transactions at this time. If, during Tuesday end of day processing at Hong Kong, pre-established sweep rules indicate that Tuesday funds should be swept 40 from the Hong Kong account 36 to the Los Angeles 38 account, such a transaction 40 could be accomplished under the current systems and methods, as the Los Angeles account 38 is still open for Tuesday transactions. However, such a transfer cannot occur the other way. A funds transfer 42 during normal business hours on Tuesday in Los Angeles from the Los Angeles account 38 to the Hong Kong account 36 cannot be done, because at this time the Hong Kong account 36 is closed for Tuesday daily transactions and open only for Wednesday transactions. Likewise, if the Tuesday end of day account processing in Los Angeles 38 (e.g., starting at midnight Los Angeles time) indicates that a sweep 44 of Tuesday funds into the Hong Kong account 36 is desired, such a transfer 44 cannot occur under the current systems and methods, because the Hong Kong account 36 is closed to Tuesday transactions. Funds in the Los Angeles account 38 on Tuesday after the Hong Kong account 36 has closed to Tuesday transactions may be transferred 46 from the Los Angeles account 38 to the Hong Kong account 36 after Tuesday end of day processing in Los Angeles 38, when both the Hong Kong 36 and Los Angeles 38 accounts are open for Wednesday transactions. This limitation restricts the use of funds deposited on Tuesday in Los Angeles 38 from being used to cover debt obligations incurred in Hong Kong 36 on Tuesday.
As a further example, consider a business operation customer of a banking entity with operations twenty-four hours a day throughout the United States. The customer has local accounts for various branches of its operation with banking entity branches throughout the country. The customer's headquarters are located in New York, and the customer would like all daily revenues from throughout the country to be transferred to their New York account at the end of each day. However, revenues received late in the day at the Los Angeles branch of the customer's operation may be received after end of day processing of the customer's New York account has begun, that is, after the New York account is closed to further daily transaction activity for the given day. Under current account processing systems and methods, such funds deposited in the customer's Los Angeles branch account late on Day N could not be transferred to the customer's New York account until Day N+1. A similar situation occurs whenever it is desired to transfer funds between accounts that are open to different day transactions due to different timing of end of day processing. This situation could occur even if it is desired only to move funds between accounts held at banking entities in the same time zone, if the accounts are on different end of day processing schedules, which often may be the case. The problem is simply exacerbated for banking entities that are spread farther apart geographically and, therefore, in time.
The ultimate effect of the situation described in the foregoing examples is that funds which should be available for customer use are not, due merely to the current systems and methods of automatic account processing. For example, with respect to the first example presented above, funds deposited by the customer into the Los Angeles account on Tuesday after Tuesday end of day account processing has begun in Hong Kong cannot be transferred to the Hong Kong account until Tuesday's processing for Los Angeles is complete, with the result that funds will not arrive for use by the customer in Hong Kong until Wednesday evening. If the customer needed additional funds in Hong Kong on Tuesday he could not make use of all of the Tuesday funds available in Los Angeles. The customer would have to find or use other funds in Hong Kong as needed. The customer may thus be forced to have available two dollars (one in Hong Kong and one in Los Angeles), where only one would be needed if the customer were not prevented by the account processing systems and methods employed to transfer same day funds between the customer's accounts.
The foregoing examples illustrate the effect of a key limitation of current account processing systems and methods. This limitation is centered in the need for accounting systems to apply transactions that are derived at multiple intervals of an account's processing cycle against an account balance that is singular in its status definition. That is, the account's balance has a singular defined status of “available for transaction posting for a given day and closed for transaction posting for all other days” in current account processing systems. However, certain transactions affecting account balances for a given day may be generated after determination of the account's closing balance for the day (i.e. after all available activity at a pre-scheduled processing time has been accumulated for a given business day). As illustrated by the examples above, such transactions may include customer requested or pre-scheduled account to account money transfer transactions that occur after a receiving account has been given a status of closed for transaction posting for the given day. These transactions which occur after the closing of transaction posting for a given day (Day N) generally cannot be applied to the account's balance until the next processing day (Day N+1). This transaction event/balance status dilemma also occurs when accounts are grouped in complex funds management arrangements that cross legal entities (chartered banks) and time zone boundaries. The event that governs processing of these funding relationships is the commonly defined account end of day account processing period. This end of day processing event is most often implemented at the institution level (e.g. all accounts for a banking entity are posted in a single “end of day” event at the same time) in current core accounting systems. With this operational system implementation, related accounts separated by even a single time zone, or even within the same time zone and on different end of day processing schedules, make posting of transfer transactions determined using account closing balances operationally unfeasible in most current accounting systems.
A further limitation of current automated account processing systems and methods is the limited flexibility that such systems and methods provide for reducing operational processing costs. As discussed above, under current systems and methods for automated account processing, all transactions and other activities affecting account balances are posted to a large group of accounts (e.g., all of a banking entity's accounts) during an end of day batch processing period. As also discussed above, all accounts being processed effectively are closed entirely to daily transactions during this processing period. To minimize the period during which the accounts are closed, every effort is made to reduce the total end of day account processing time. This may be achieved both by maximizing processing efficiency and by maximizing available processing resources to process a large number of transactions for a large number of accounts in as brief a period of time as possible. The additional processing resources required to minimize processing times for a large number of transactions and accounts also increases operational costs. Computer resources, and resulting operating costs, may be reduced if a system and method for automated account processing provided more flexibility in the time periods over which different types of transactions might be posted to different accounts, rather than requiring all transactions to be posted to all banking entity accounts in the shortest possible time, as required by current systems and methods.
A more conceptual limitation of current automated account processing systems and methods is the anomalies that can arise from practical compromises which result from the attempt to fit in additional closing transactions on top of ending balances calculated during the end of day account processing period in order to reflect such transactions in next day opening positions. For example, in current account processing systems and methods, as discussed above, service charges and interest are calculated against ending balances for a given Day N and posted to the given Day N balance during end of day account processing for the given Day N. Thus, the interest and service charge calculations that are to be based on the end of day closing balance for a given Day N actually affect the given Day N closing balance on which they should be based. Interest and service charge entries would be handled more accurately by the account processing system as opening transactions for the next day (Day N+1). However, in the current systems and methods for automated account processing, all activity affecting the next Day N+1 balance is not posted until the day is over. Clearly, a customer would not accept a delay in posting of interest based on an account balance for Day N until after the next Day N+1 is over. Similarly, the banking entity would not want to delay charging service charges to an account balance for Day N until the next Day N+1 was over.
What is desired, therefore, is an automated account processing system and method which overcomes the limitations of current account processing systems and methods, in which virtually all account activity final posting occurs during an end of day batch account processing period during which all daily transaction processing for that day is closed and after which all daily transactions are processed as next day activity. The desired automated account processing system and method preferably provides greater flexibility in the time periods over which various transactions affecting account balances may be posted to various accounts.